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Status of Claims 

Claims 7-19, 22-25, 28-30, 32, 33, and 37-39 are objected to as being dependent 
upon a rejected base claim but would be allowable if rewritten in independent form. 

Claims 1-20, 21, 26, 27, 31, 34-36, and 40-43, which are pending in this 
application, stand finally rejected. 

All claims are being appealed herein. 

A copy of the claims as now presented are appended to this brief in the Claims 
Appendix attached hereto. 

Status of Amendments 

All amendments to the claims have been entered. 

Summary of Claimed Subject Matter 

All of the independent claims overcome the problem of the prior art of 
determining whether an internet protocol (IP) packet contains video, by actually 
determining that a packet contains MPEG-2 video rather than using predefined streams or 
priority levels that are assumed to contain such information, or any other IP packet header 
information, as is done in the prior art. More specifically, in accordance with an aspect of 
the invention, the "sync" bytes of the MPEG-2 stream are searched for within the IP 
packet payload, and when a pattern indicative of the sync bytes is found the sync bytes are 
identified and the packet is determined to contain MPEG-2 video. The sync byte was 
defined in MPEG-2 for over-the-air broadcasting in order that a television receiver be 
able to synchronize the MPEG-2 transport stream packets. Note that the MPEG-2 video, 
e.g., the MPEG-2 transport stream packets, may, or may not, be incorporated within real 
time protocol (RTP) packets before being incorporated into the IP packets. See 
applicants 5 specification, page 2, lines 20-31. 

Furthermore, as explained in connection with FIG. 1, at page 5, lines 14-27, in 
accordance with the principles of the invention, due to the regular spacing of the sync 
byte, it is possible to search through UDP data payload 111 for the presence of the 
expected pattern of MPEG-2 video, i.e., a pattern of having a sync byte as the first byte of 
UDP data payload 111 — after any optional RTP header — and thereafter having a sync 
byte at each byte position in UDP data payload 1 1 1 that is a multiple of 188. Although 
finding a sync byte as the first byte of UDP data payload 111, after any optional RTP 
header, gives a strong indication that the IP packet contains MPEG-2 video, and it is 
assumed that for UDP data payloads of length 188 for which the first byte has the value 
of a sync byte that the packet contains MPEG-2 video, preferably each potential sync byte 



C:\PATENTS\Hearn l-21-l\Hearn 1-21-1 appeal.doc 



2 



Serial No. 09/608,473 



position should be checked. This is because the confidence level that MPEG-2 video has 
actually been found increases substantially when each position indeed contains a sync 
byte value. 

FIG. 3 shows an exemplary process, in flowchart form, for processing an IP 
packet to determine if it contains MPEG-2 video, in accordance with the principles of the 
invention. 

Grounds of Rejection to be Reviewed on Appeal 

I. The rejection of 1-19 under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention because of the use of the phrase "may be" is the first 
ground of rejection to be reviewed. 

II. The rejection of claims 1-6, 20-21, 26-27, 31, 34-36, and 40-43 under 35 
U.S.C. 102(e) as being anticipated by United States Patent No. 6,557,031 issued to 
Mimura et al. on April 29, 2003 is the second ground of rejection to be reviewed. 

Argument 

Ground I - Rejection Under 35 U.S.C. 112, Second Paragraph 

Claims 1-19 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. The Office Action states that the phrase "may be" 
renders the claim indefinite because it is unclear whether the limitations following the 
phrase are part of the claimed invention. 

Applicants respectfully traverse this ground of rejection for the following reason. 

Applicants note that the words following "may be" are not so much limitations of 
the claimed invention but rather are merely descriptive of a conventional element that 
may, but need not, exist within an IP data payload. As such, the "may be" language is an 
accurate characterization of the IP data payload, in that it accurately characterizes the 
environment in which the invention may operate. Furthermore, as will be explained in 
more detail hereinbelow, whether the IP data payload contains the conventional element, 
is irrelevant. 

More specifically, claim 1 states "the contents of said IP data payload of said IP 
packet exclusive of any information in any real time protocol (RTP) header which may be 
therein". Thus, the actual phrase of interest for the claim is "any real time protocol (RTP) 
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header which may be therein" in its entirety, rather than simply the word "therein" which 

follows the words "may be". This phrase characterizes an RTP header, which is the 

conventional element that may, or may not, be within the IP data payload of any particular 

IP packet. It is essentially the equivalent of stating "the contents of said IP data payload 

of said IP packet exclusive of any information in any real time protocol (RTP) header 

existing therein". Clearly, using such a formulation, the words "may be" have been 

eliminated. However, the conditionality as to whether or not an RTP header exists in the 

packet remains, because it actually stems from use of the word "any". Applicants believe 

that their recitation is somewhat clearer. Applicants note that use of the word "may", just 

like use of the word "or" does not necessarily render a claim indefinite. 

A careful reading of the claim reveals if the IP data payload does not contain an 

RTP header, then of course, it cannot be employed in the step of identifying, since it is 

not there. Likewise, if an RTP header is included in the IP data payload, then it is not 

employed in the step of identifying, because the claim language excludes it from use. So, 

whether or not an RTP header is present in the IP data payload, the result is the same, i.e., 

no use is made in the identifying step of any information in any RTP header which might 

be in the IP data payload. 

Thus, the claim language is definite, notwithstanding the present of the term "may 

be". Indeed, the definite meaning of the claim would be readily apparent to one of 

ordinary skill in the art. In support of this notion, applicants note that the European 

counterpart to this application has issued in Great Britain, France and Germany (1 175098, 

1175098, 60100204.0), as shown in the Evidence Appendix attached hereto, with a very 

similar claim 1 that has the same phrase "may be" as follows: 

A method for processing an internet protocol (IP) packet (101,111), 
comprising the step of identifying that said packet contains motion picture 
expert group (MPEG)-2 video as a function of only the contents of said IP 
data payload (111) of said IP packet exclusive of any information in any 
real time protocol (RTP) header which may be within said IP data payload. 

While applicants recognize that the Unite States Patent and Trademark Office 
does not give deference to any other patent-related body around the world, nevertheless, 
applicant are citing this European patent as evidence of that those ordinary skill in the art, 
whom the European Examiner may be considered to be, or to represent, would consider 
such language to be clear and definite. 
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Ground 2 - Rejection of Claims 1-6, 20-21, 26-27, 31, 34-36, and 40-43 Under 35 
U.S.C. 102 

Claims 1-6, 20-21, 26-27, 31, 34-36, and 40-43 are rejected under 35 U.S.C. 
102(e) as being anticipated by United States Patent No. 6,557,03 1 issued to Mimura et al. 
on April 29, 2003. 

The Office Action states that Mimura et al. teaches all the limitations of the 
rejected claims. 

This ground of rejection is traversed for the following reasons. 

Firstly, applicants note that their invention is only directed at identifying those IP 
packets that contain video. Thus, all of the sections of Mimura et al. relating to placing 
MPEG video from a known MPEG video source, e.g., as received from a cable television 
or satellite system, within an IP packet, such as column 2, lines 29-54, are totally 
irrelevant to applicants' invention. This is because it is know in advance that all that can 
come out from the known MPEG video source is MPEG video. There is, therefore, no 
need to examine such content. The fact that it is MPEG content is already known. 

Furthermore, in Mimura et al. IP packets do not come out from those sources. 
This is because MPEG Transport stream (TS) packets are not IP packets. So any 
processing in Mimura et al. of TS packets is excluded from the scope of applicants' 
claims, even if it were to use the same techniques disclosed by applicants, which is not 
the case. 

Secondly, those sections of Mimura et al. that relate to extracting MPEG video 
from IP packets do not teach applicants 5 invention. Instead, they determine that the IP 
packets contain MPEG video based on other techniques which do not render applicants' 
invention obvious. 

More specifically, in Mimura et al., an IP packet is known to contain video based 
on address information . This can be seen, for example, from column 4, lines 52 through 
column 6, line 47, in which it is oft repeated that Mimura et al. assigns a correspondence 
from the IP address of the IP packets containing video to a PID value, which is the 13 -bit 
packet identifiers that come after the synchronization byte in the MPEG video transport 
stream (TS), which is used then used to route the TS video in the MPEG video network, 
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e.g., a cable television or satellite system. In other words, it seems that in Mimura et al. 
that IP packets that contain MPEG video are identified based on information in the IP 
header, namely, an address, and then the PID is assigned or associated therewith. Clearly 
then in Mimura et al., the identification of a packet as containing video is not based on 
only information in the payload of the IP packet, as required by applicants' claims. 

The sections of Mimura et al. cited in connection with claims 20-21, 31, 34-36, 
40-43, namely, column 9, line 5 to column 12, line 15, do not teach searching through a 
payload of an IP packet for a pattern and indicating that the packet contains MPEG video 
only if the pattern is found, nor does it teach determining whether a payload of an IP 
packet has a length equal to an integral multiple of the length of an MPEG-2 transport 
stream packet. Rather, most of that section deals with forming an MPEG transport stream 
packet which include IP header information. No searching of IP packets is done for this 
purpose, and in fact IP packets don't even exist . And when, in the cited section, MPEG 
video in IP packets is to be extracted for conversion to transport stream packets, there is 
no searching involved. In the cited section it is assumed that the IP packets are known to 
contain video. Instead, as explained in subsequent sections, as well as column 4, lines 52 
through column 6, line 47, this appears to be based on the IP header information of the IP 
packet, and not based on the content of the data payload of the IP packet, which seems to 
only contain MPEG video in PES format. 

Thus, there is no teaching or suggestion in Mimura et al. to determine that an IP 
packet contains MPEG-2 data based solely on the IP data payload, exclusive of any RTP 
header therein. 

Additionally, regarding claim 27, the cited section of Mimura et al., i.e., column 9, 
line 43 through column 10, line 11, does not teach processing the IP packet with a 
priority assigned for packets containing video when the indicating step indicates that the 
IP packet contains video. This is because that section is related to the formation of 
MPEG-TS signals which include IP header information, so there are no actual IP packets 
at this point, and so there cannot be any processing of IP packets. Also, the cited section 
does not have an IP packet that was identified as having video based on only the IP data 
payload, because there was no identification of IP packets at this point, as recited in claim 
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27. Moreover, no language in the cited section contained therein indicates any type of 
priority processing. Indeed, the word "priority", or any synonym therefor, does not seem 
to appear in the cited section. 

Applicants note that their claims clearly exclude any information in the RTP 
header from being considered in determining whether an MPEG video signal is present or 
not. Thus, only non-header information of any type is searched and used to determine the 
presence of MPEG video. However, there is no such teaching in Mimura et al. 

Applicants note that claims of nearly identical wording were allowed by the EPO 
as European Patent No. 1175098, which has issued in Great Britain, France, and 
Germany. A copy of this European Patent is attached hereto in the Evidence Appendix. 
While applicants recognize that the United States Patent and Trademark Office does not 
defer to any other body, nevertheless, such an allowance is strong independent evidence 
that applicants' claims clearly recite a novel and not obvious invention that is adequately 
supported by the originally filed specification. 

Thus, all of applicants' independent claims, and hence all of applicants' 
dependent claims, are allowable over Mimura et al. 
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Conclusion 

In view of the foregoing, it is submitted that the Examiner is in error. It is, 
accordingly, respectfully requested that the rejection of claims 1 -20, 21 , 26, 27, 3 1 , 34-36, 
and 40-43 be reversed, and the application passed to issue. 



Respectfully, 



J. P. Hearn 



K. N. Matthews 



C.C. Yu 




Eugene J. Rcfsenthal, Attorney 
Reg. No. 36,658 
732-949-1857 



Lucent Technologies Inc. 
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Claims Appendix 

1 1. (Previously presented) A method for processing an internet protocol (IP) 

2 packet, comprising the step of identifying that said packet contains motion picture expert 

3 group (MPEG)-2 video as a function of only the contents of said IP data payload of said 

4 IP packet exclusive of any information in any real time protocol (RTP) header which may 

5 be therein. 

1 2. (original) The invention as defined in claim 1 wherein said MPEG-2 video is 

2 in transport stream format. 

1 3. (original) The invention as defined in claim 1 wherein said IP data payload 

2 contains at least one real time protocol (RTP) packet which contains said MPEG-2 video. 

1 4. (original) The invention as defined in claim 1 wherein said IP data payload is a 

2 unreliable datagram protocol (UDP) data payload. 

1 5. (original) The invention as defined in claim 1 wherein said IP data payload is a 

2 transmission control protocol (TCP) data payload. 

1 6. (original) The invention as defined in claim 1 further comprising the step of 

2 processing said IP packet with a priority assigned for packets containing video when said 

3 packet is identified in said identifying step to contain video. 

1 7. (original) The invention as defined in claim 1 wherein said identifying step 

2 further includes the steps of: 

3 determining whether or not there exists within said IP data payload at least an 

4 expected pattern of MPEG-2 sync bytes that is indicative of the presence of MPEG-2 

5 video. 
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1 8. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 comparing a first byte of said IP data payload after any real time protocol (RTP) 

4 header to the value of an MPEG-2 sync byte; and 

5 when the result of said comparing step is that said first byte of said IP data 

6 payload has the same value as an MPEG-2 sync byte, declaring said IP packet to be an 

7 MPEG-2 packet. 



1 9. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 comparing a first byte of said IP data payload after any real time protocol (RTP) 

4 header to the value of an MPEG-2 sync byte; and 

5 when the result of said comparing step is that said first byte of said IP data 

6 payload is an MPEG-2 sync byte and the length of said IP data payload after any RTP 

7 header is the same as the length of an MPEG-2 transport stream packet, declaring said IP 

8 packet to be an MPEG-2 packet. 
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1 10. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 terminating said process and indicating that said expected pattern does not exist in 

4 said packet unless the length of said IP data payload or the length of said IP data payload 

5 less the length of a real time protocol (RTP) header is an integral multiple of the length of 

6 an MPEG-2 transport stream packet; 

7 pointing a pointer to a byte in said IP data payload, said byte being a first byte of 

8 said IP data payload when said length of said IP data payload is an integral multiple of the 

9 length of an MPEG-2 transport stream packet and said byte being a first byte of said IP 

10 data payload after the length of a real time protocol (RTP) header when said IP data 

1 1 payload less the length of a real time protocol (RTP) header is an integral multiple of the 

1 2 length of an MPEG-2 transport stream packet; 

1 3 performing a comparison between said byte being pointed to with the value of an 

14 MPEG-2 sync byte and declaring said IP packet as a candidate to be an MPEG-2 packet 

15 when the result of a most recent comparison is that said pointed to byte of said IP data 

1 6 payload has the same value as an MPEG-2 sync byte 

17 adjusting said pointer to point to byte in said IP data payload that is offset toward 

1 8 the end of said IP packet by the length of an MPEG-2 transport stream packet; 

19 repeating said performing and adjusting steps so long as said most recently 

20 executed performing step declared said IP packet as a candidate to be an MPEG-2 packet 

21 and the end of said IP data payload is not yet reached; and 

22 declaring said packet to be an MPEG-2 packet when the end of said IP data 

23 payload is reached during an attempt to execute said adjusting step and said most recently 

24 executed performing step declared said IP packet as a candidate to be an MPEG-2 packet. 

1 11. (original) The invention as defined in claim 7 wherein said expected pattern 

2 is an MPEG-2 sync byte value spaced 188 byte positions apart. 

1 12. (original) The invention as defined in claim 7 wherein said expected pattern 

2 is an MPEG-2 sync byte value spaced apart by the length of an MPEG-2 transport stream 

3 packet. 
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1 13. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 declaring said IP packet to be an MPEG-2 packet when a search over the length of 

4 a real time protocol header and the length of one MPEG-2 transport stream packet finds 

5 sync byte for which offset therefrom by the length of one MPEG-2 transport stream 

6 packet there is another sync byte. 

1 14. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 declaring said IP packet to be an MPEG-2 packet when a search over the length of 

4 a real time protocol header and the length of one MPEG-2 transport stream packet finds 

5 the value of a sync byte for which offset therefrom at each integral multiple of the length 

6 of one MPEG-2 transport stream packet there is the value of a sync byte until the end of 

7 said IP packet is reached or exeeded. 

1 15. (original) The invention as defined in claim 7 wherein said determining step 

2 further comprises the step of: 

3 declaring said IP packet to be an MPEG-2 packet when a search over the length of 

4 a real time protocol header and the length of one MPEG-2 transport stream packet finds 

5 the value of a sync byte for which offset therefrom by the length of one MPEG-2 

6 transport stream packet there is the end of packet. 

1 16. (original) The invention as defined in claim 7 wherein said each of said sync 

2 bytes has a value of 0x47. 

1 17. (original) The invention as defined in claim 7 wherein said at least one 

2 expected pattern is the value of an MPEG-2 sync byte as the first byte of said IP data 

3 payload. 



1 18. (original) The invention as defined in claim 7 wherein said expected pattern 

2 is the value of an MPEG-2 sync byte as the first byte of said IP data payload and every 

3 188 bytes thereafter till the end of said IP data payload. 
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1 19. (original) The invention as defined in claim 7 wherein said at least one 

2 expected patterns includes at least one of the sets of patterns consisting of: a) the value of 

3 an MPEG-2 sync byte as the first byte of said IP data payload after the length of a real 

4 time protocol (RTP) header and said IP data payload after said RTP header length has a 

5 length of 188 bytes, b) the value of an MPEG-2 sync byte as the first byte of said IP data 

6 payload after the length of a real time protocol (RTP) header and every 188 bytes 

7 thereafter till the end of said IP data payload, c) the value of an MPEG-2 sync byte as the 

8 first byte of said IP data payload and every 188 bytes thereafter till the end of said IP data 

9 payload, d) the value of an MPEG-2 sync byte as the first byte of said IP data payload and 
10 said IP data payload has a length of 1 88 bytes. 



1 20. (Previously presented) A method for processing an internet protocol (IP) 

2 packet, comprising the steps of: 

3 searching through a payload of said IP packet exclusive of any information in any 

4 real time protocol (RTP) header therein for a pattern indicative of the presence of motion 

5 picture expert group (MPEG)-2 video; and 

6 indicating that said IP packet contains MPEG-2 video only if said pattern is found. 

1 21. (original) The invention as defined in claim 20 wherein said searching step 

2 further includes the step of: 

3 determining whether a payload of said IP packet has a length equal to an integral 

4 multiple of a length of an MPEG-2 transport stream packet either before or after 

5 subtracting from said payload length the length of an RTP head. 

1 22. (original) The invention as defined in claim 20 wherein said searching step 

2 further includes the steps of: 

3 determining that a payload of said IP packet has a length equal to a length of an 

4 MPEG-2 transport stream packet; 

5 comparing the value of a first byte at a first location within said packet with the 

6 value of an MPEG-2 sync byte; and 

7 signaling said pattern is found when the result of said comparing step is that said 

8 value of said first byte at said first location matches the value of said sync byte. 
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1 23. (original) The invention as defined in claim 20 wherein said searching step 

2 further includes the step of: 

3 determining whether a payload of said IP packet has a length equal to an integral 

4 multiple of a length of an MPEG-2 transport stream packet, 

5 comparing the value of a first byte at a first location within said packet and each 

6 byte at an offset of a length of an MPEG-2 transport stream packet therefrom with the 

7 value of an MPEG-2 sync byte; and 

8 signaling said pattern is found when the result of each comparison performed in 

9 said comparing step is that said first byte of said packet being compared matches the 
10 value of said sync byte. 

1 24. (original) The invention as defined in claim 20 wherein said searching step 

2 further includes the step of: 

3 determining whether a payload of said IP packet has a length equal to an integral 

4 multiple of a length of an MPEG-2 transport stream packet, 

5 comparing the value of a first byte at a first location within said packet and each 

6 byte at an offset of a length of an MPEG-2 transport stream packet therefrom with the 

7 value of an MPEG-2 sync byte; and 

8 signaling said pattern is found when the result of a majority of comparisons 

9 performed in said comparing step is that said first byte of said packet being compared 
10 matches the value of said sync byte. 

1 25. (original) The invention as defined in claim 20 wherein said searching step 

2 further includes the step of: 

3 determining whether a payload of said IP packet has a length equal to an integral 

4 multiple of a length of an MPEG-2 transport stream packet, 

5 comparing the value of a first byte at a first location within said packet and each 

6 byte at an offset of a length of an MPEG-2 transport stream packet therefrom with the 

7 value of an MPEG-2 sync byte; and 

8 signaling said pattern is found when the result of at least a majority of 

9 comparisons performed in said comparing step is that said first byte of said packet being 

10 compared matches the value of said sync byte and said packet was indicated to contain an 

1 1 error. 
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1 26. (original) The invention as defined in claim 20 wherein said payload is at 

2 least one of a set of payloads within an IP packet, said set consisting of: a) an IP data 

3 payload, b) an unreliable datagram protocol (UDP) data payload that does not include a 

4 real time protocol (RTP) header, c) that portion of a UDP data payload after an RTP 

5 header that is included in said UDP data payload, and d) a transmission control protocol 

6 (TCP) data payload. 



1 27. (original) The invention as defined in claim 20 further comprising the step of 

2 processing said IP packet with a priority assigned for packets containing video when said 

3 indicating step indicates that said IP packet contains video. 



1 28. (original) The invention as defined in claim 20 wherein said pattern 

2 corresponds to the value of an MPEG-2 sync byte regularly spaced from an initial 

3 position through the end of said payload, said regular spacing being equal to the length of 

4 an MPEG-2 transport stream packet, said initial position being located within the length 

5 of a real time protocol header and the length of one MPEG-2 transport stream packet 

6 from a start of said payload. 



1 29. (original) The invention as defined in claim 20 wherein said pattern 

2 corresponds to the value of an MPEG-2 sync byte and the end of said IP packet spaced 

3 apart by the length of one MPEG-2 transport stream packet, said initial position being 

4 located within the length of a real time protocol header and the length of one MPEG-2 

5 transport stream packet from a start of said payload. 



1 30. (original) The invention as defined in claim 20 wherein said pattern 

2 corresponds to the value of an MPEG-2 sync byte regularly spaced from an initial 

3 prescribed position, said regular spacing being equal to the length of an MPEG-2 

4 transport stream packet. 
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1 31. (Previously presented) A method for processing an internet protocol (IP) 

2 packet, comprising the steps of: 

3 searching through a payload of said IP packet exclusive of any information in any 

4 real time protocol (RTP) header therein for a pattern indicative of the presence of motion 

5 picture expert group (MPEG)-2 video; and 

6 indicating that said IP packet contains MPEG-2 video when said pattern is most 

7 likely found. 

1 32. (original) The invention as defined in claim 31 wherein said pattern 

2 corresponds to an MPEG-2 sync byte regularly spaced from an initial prescribed position, 

3 said regular spacing being equal to the length of an MPEG-2 transport stream packet. 

1 33. (original) The invention as defined in claim 32 wherein said initial prescribed 



2 position is a position within the group of positions consisting of: a) the first byte in an IP 

3 data payload of said packet, b) the first byte of a UDP payload of said IP packet, c) the 

4 first byte after an RTP header of an unreliable datagram protocol (UDP) payload of said 

5 IP packet, d) the first byte of a transport control protocol (TCP) payload of said IP packet, 

6 and e) the first byte of a TCP payload after a header contained therein indicating real time 

7 information is contained in said IP packet. 



1 34. (original) The invention as defined in claim 31 further comprising the step of 

2 processing said IP packet with a priority assigned for packets containing video when said 

3 indicating step indicates that said IP packet contains video. 

1 35. (Previously presented) A method for processing an internet protocol (IP) 

2 packet, comprising the steps of: 

3 searching through a payload of said IP packet exclusive of any information in any 

4 real time protocol (RTP) header therein for a pattern indicative of video; and 

5 indicating that said IP packet contains video when said pattern is found; and 

6 indicating that said IP packet does not contain video when said pattern is not 

7 found. 
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1 36. (original) The invention as defined in claim 35 further comprising the step of 

2 processing said IP packet with a priority assigned for packets containing video when it is 

3 indicated that said IP packet contains video. 



1 37. (original) The invention as defined in claim 35 wherein said pattern 

2 corresponds to the value of an MPEG-2 sync byte regularly spaced from an initial 

3 position through the end of said payload, said regular spacing being equal to the length of 

4 an MPEG-2 transport stream packet, said initial position being located within the length 

5 of a real time protocol header and the length of one MPEG-2 transport stream packet 

6 from a start of said payload. 

1 38. (original) The invention as defined in claim 35 wherein said pattern 

2 corresponds to the value of an MPEG-2 sync byte regularly spaced from an initial 

3 prescribed position, said regular spacing being equal to the length of an MPEG-2 

4 transport stream packet. 



1 39. (original) The invention as defined in claim 38 wherein said initial prescribed 

2 position is a position within the group of positions consisting of: a) the first byte in an IP 

3 data payload of said packet, b) the first byte of a UDP payload of said IP packet, c) the 

4 first byte after an RTP header of an unreliable datagram protocol (UDP) payload of said 

5 IP packet, d) the first byte of a transport control protocol (TCP) payload of said IP packet, 

6 and e) the first byte of a TCP payload after a header contained therein indicating real time 

7 information is contained in said IP packet. 



1 40. (Previously presented) A computer program in the form of machine readable 

2 instructions, said computer program being for causing a system including a processor to: 

3 search through a payload of an internet protocol (IP) packet exclusive of any 

4 information in any real time protocol (RTP) header therein for a pattern indicative of the 

5 video; 

6 indicate that said IP packet contains video when said pattern is found; and 

7 indicate that said IP packet does not contain video when said pattern is not found. 
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1 41. (original) The invention as defined in claim 40 wherein said computer 

2 program further causes said processor to 

3 process said IP packet with a priority assigned for packets containing video when 

4 said IP packet is indicated to contain video. 

1 42. (Previously presented) Apparatus comprising: 

2 a processor; 

3 a memory coupled to said processor for storing a received internet protocol (IP) 

4 packet; and 

5 a program store; 

6 wherein said program store contains instructions for causing said processor to 

7 search through a payload of an internet protocol (IP) packet exclusive of any 

8 information in any real time protocol (RTP) header therein for a pattern indicative of the 

9 video; 

10 indicate that said IP packet contains video when said pattern is found; and 

1 1 indicate that said IP packet does not contain video when said pattern is not found. 

1 43. (Previously presented) Apparatus, comprising: 

2 means for searching through a payload of an internet protocol (IP) packet 

3 exclusive of any information in any real time protocol (RTP) header therein for a pattern 

4 indicative of video; and 

5 means for indicating that said IP packet contains video when said pattern is found. 
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Description 
Technical Field 

[0001] This invention relates to the art of transmitting 
real-time-constrained information over internet protocol 
(IP) networks, and more particularly, to identifying par- 
ticular streams of real-time-constrained information, 
such as video encoded using Motion Pictures Expert 
Group (MPEG)-2 encoding, so that they may be given 
appropriate processing treatment. 

Background of the Invention 

[0002] A problem in the art of transmitting packets 
containing real-time-constrained information over inter- 
net protocol (IP) networks is the need to give each type 
of information the appropriate processing. In order to do 
this, it is necessary to know the type of information that 
is contained within each packet as it passes through the 
network at each point at which the packet will be proc- 
essed. In particular, video, such as using Motion Pic- 
tures Expert Group (MPEG)-2 encoded video, cannot 
withstand dropped packets. Therefore, in processing 
streams of packets that contain MPEG-2 video, it is nec- 
essary to give priority to any MPEG-2 video streams 
over other streams which are less sensitive, or insensi- 
tive, to dropped packets. 

[0003] Prior art techniques prioritize packets based 
on predefined criteria without actually ascertaining, e. 
g., by investigating the contents of the packet, that the 
packets actually contain MPEG-2 video. For example, 
a packet flow may be defined and it is assumed that all 
packets in that flow are MPEG-2 packets, and packets 
from that flow are treated as if they contain MPEG-2 
packets without regard for their actual contents. A flow 
is often defined by specifying source and destination IP 
addresses for the flow, or by specifying the source/des- 
tination port address thereof. 

[0004] Another prior art technique that is used to pri- 
oritize packets is based upon the so-called "type-of- 
service" (TOS) byte, which is part of the IP packet head- 
er. The TOS may be used to indicate a coarse prioriti- 
zation, so that, for example, it is assumed that any pack- 
et with either a predefined value in the TOS byte, or a 
value in the TOS byte that is at least a predefined value, 
contains MPEG-2 video and is treated appropriately. 
[0005] Because these prior art techniques do not ac- 
tually investigate the contents of the packet to be certain 
that it contains MPEG-2 video, it is possible that packets 
that do not contain MPEG-2 video will be processed as 
if they contained MPEG-2 video. Provided that there is 
sufficient bandwidth in the processing system, process- 
ing these non-MPEG-2 packets, i.e., these fake.MPEG- 
2 packets, as if they were indeed actual MPEG-2 pack- 
ets is not a problem. However, in the face of limited 
bandwidth-and what system does not have limited 
bandwidth-processing these fake MPEG-2 packets as 



undroppable actual MPEG-2 packets unnecessarily 
consumes system resources. Furthermore, these prior 
art prioritization arrangements can be abused by an un- 
scrupulous user who sets his flow, or TOS byte, to indi- 
5 cate that he is sending MPEG-2 video, when in reality 
he is not. 

[0006] In addition, setting up the flows in an IP net- 
work — the flows being a static configuration that spec- 
ifies fixed ports — requires administration and/or recon- 

10 figuration each time a flow needs to be changed, i.e., a) 
when a point to point connection changes one of its 
points, b) when a new connection is made, ore) the like. 
Note that each switch or processing unit through which 
an MPEG-2 video stream flows must be updated with 

is the new flow identifying information each time a flow 
needs to be changed. Thus, there is a constant admin- 
istrative burden due to the resulting flow churn. 
[0007] Another problem that arises in prior art ar- 
rangements using the TOS byte to define a flow that is 

20 to contain MPEG-2 video is the need for all of switches 
or processing units through which the flow passes to 
agree to a common TOS byte value, or set of values, 
that indicate MPEG-2 video. Otherwise, some switches 
or processing units may not properly handle, e.g., may 

25 drop, the MPEG-2 packets. It is difficult in practice to 
arrange for such agreement, especially when the flow 
travels over multiple networks. 

[0008] A. PURI, T Chen: 'Multimedia Systems, Stand- 
ards, and networks' (chapter 1 8) March 2000 (2000-03), 
30 MARCEL DEKKER XP0021 83848 ISBN: 082479303X 
teaches delivery and control of MPEG-4 content over I P 
networks. The contents of a packet stream are identified 
by the use of header bits. 

[0009] WO-A-98/1 8233 teaches a device and method 
35 for finding the sync pattern of a fixed-length packetized 
bitstream, e.g., an MPEG-2 transport stream. This is 
achieved using a histogram of occurrences of the sync 
pattern. 



[0010] A method and apparatus according to the in- 
vention are as set out in the independent claims. 
[0011] We have recognized that that the problems 
with the prior art can be overcome, in accordance with 
the principles of the invention, by actually determining 
that a packet contains MPEG-2 video rather than using 
predefined streams or priority levels that are assumed 
to contain such information as is done in the prior art. 
More specifically, in accordance with an aspect of the 
invention, the "sync" bytes of the MPEG-2 stream are 
searched for within the IP packet payload, and when a 
pattern indicative of the sync bytes is found the sync 
bytes are identified and the packet is determined to con- 
tain MPEG-2 video. The sync byte was defined in 
MPEG-2 for over-the-air broadcasting in order that a tel- 
evision receiver be able to synchronize the MPEG-2 
transport stream packets. Note that the MPEG-2 video, 
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e.g., the MP EG-2 transport stream packets, may or may 
not be incorporated within real time protocol (RTP) 
packets before being incorporated into the IP packets. 

Brief Description of the Drawing 

[0012] In the drawing: 

FIG. I shows internet protocol (IP) packet that is of 
the general type for which a determination may be 
made as to whether or not it contains M PEG-2 video 
based only on the packet's IP data payload in ac- 
cordance with the principles of the invention; 
FIG, 2 shows an expanded version of a portion of 
the packet shown in FIG. 1 ; and 
FIG. 3 shows an exemplary process, in flowchart 
form, for processing an IP packet to determine if it 
contains MPEG-2 video, in accordance with the 
principles of the invention. 

Detailed Description 

[0013] The following merely illustrates the principles 
of the invention. It will thus be appreciated that those 
skilled in the art will be able to devise various arrange- 
ments which, although not explicitly described or shown 
herein, embody the principles of the invention and are 
included within its spirit and scope. Furthermore, all ex- 
amples and conditional language recited herein are 
principally intended expressly to be on ly for pedagogical 
purposes to aid the reader in understanding the princi- 
ples of the invention and the concepts contributed by 
the inventor(s) to furthering the art, and are to be con- 
strued as being without limitation to such specifically re- 
cited examples and conditions. Moreover, all state- 
ments herein reciting principles, aspects, and embodi- 
ments of the invention, as well as specific examples 
thereof, are intended to encompass both structural and 
functional equivalents thereof. Additionally, it is intended 
that such equivalents include both currently known 
equivalents as well as equivalents developed in the fu- 
ture, i.e., any elements developed that perform the 
same function, regardless of structure. 
[0014] Thus, for example, it will be appreciated by 
those skilled in the art that the block diagrams herein 
represent conceptual views of illustrative circuitry em- 
bodying the principles of the invention. Similarly, it will 
be appreciated that any flow charts, flow diagrams, state 
transition diagrams, pseudocode, and the like represent 
various processes which may be substantially repre- 
sented in computer readable medium and so executed 
by a computer or processor, whether or not such com- 
puter or processor is explicitly shown, 
[0015] The functions of the various elements shown 
in the FIGs., including functional blocks labeled as 
"processors", may be provided through the use of ded- 
icated hardware as well as hardware capable of execut- 
ing software in association with appropriate software. 



When provided by a processor, the functions may be 
provided by a single dedicated processor, by a single 
shared processor, or by a plurality of individual proces- 
sors, some of which may be shared. Moreover, explicit 
s use of the term "processor" or "controller" should not be 
construed to refer exclusively to hardware capable of 
executing software, and may implicitly include, without 
limitation, digital signal processor (DSP) hardware, 
read-only memory (ROM) for storing software, random 
10 access memory (RAM), and non-volatile storage. Other 
hardware, conventional and/or custom, may also be in- 
cluded. Similarly, any switches shown in the FIGS, are 
conceptual only. Their function may be carried out 
through the operation of program logic, through dedicat- 
es ed logic, through the interaction of program control and 
dedicated logic, or even manually, the particular tech- 
nique being selectable by the implementor as more spe- 
cifically understood from the context. 
[0016] In the claims hereof any element expressed as 
20 a means for performing a specified function is intended 
to encompass any way of performing that function in- 
cluding, for example, a) a combination of circuit ele- 
ments which performs that function or b) software in any 
form, including, therefore, firmware, microcode or the 
25 like, combined with appropriate circuitry for executing 
that software to perform the function. The invention as 
defined by such claims resides in the fact that the func- 
tionalities provided by the various recited means are 
combined and brought together in the manner which the 
30 claims call for. Applicant thus regards any means which 
can provide those functionalities as equivalent as those 
shown herein. 

[0017] Unless otherwise explicitly specified herein, 
the drawings are not drawn to scale. 

35 [0018] FIG. 1 shows internet protocol (IP) packet 101 
that is of the general type for which a determination may 
be made as to whether or not it contains M PEG-2 video 
based only on the packet's IP data payload in accord- 
ance with the principles of the invention. More specifi- 

40 cally, in accordance with an aspect of the invention, a 
search is performed for the "sync" bytes of the MPEG- 
2 stream within the IP packet data payload of packet 
101. When a pattern indicative of the sync bytes is 
found, the packet is determined to contain MPEG-2 vid- 

45 eo. Otherwise, the packet is determined to contain in- 
formation that is not MPEG-2 video. 
[001 9] Packet 1 01 has a series of headers which pre- 
cede I P data payload 111. In particular, packet 1 01 con- 
tains IP header 105, which is 20 bytes long and unreli- 

so able datagram protocol/transmission control protocol 
(UDP/TCP) header 107, which is 8 bytes long. Note that 
conventionally IP header 1 05 and UDP/TCP header 1 07 
are conventionally grouped together and referred to as 
the header for the IP packet. They are shown independ- 

55 ently in FIG. 1 for clarity of exposition and pedagogical 
purposes only. 

[0020] Note that IP packet 1 01 , as shown, is a U DP 
packet. This is because, as of this writing, UDP is typi- 
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cally used for real-time streaming, as TCP requires end- 
to-end communication. Thus, the invention is described 
herein in terms of UDP packets in IP. However, those of 
ordinary skill in the art will readily recognize how to apply 
the principles of the invention to TCP packets. 5 
[0021] IP data payload 111 follows UDP/TCP header 
109. The number of bytes that are contained within IP 
data payload 111 is flexible, ranging from 0 and up, al- 
though certain transmission arrangements, such as eth- 
ernet, may impose other limits. Optional real time pro- 
tocol (RTP) header 1 09, if present, is 12 bytes long, and 
is within IP data payload 111 . 

[0022] FIG. 2 shows an expanded version of IP data 
payload 111, which, as packet 101 is a UDP packet, is 
a UDP data payload. FIG. 2 shows an example in which 
UDP data payload 111 is carrying MPEG-2 video. As in- 
dicated, RTP header 109 may precede the MPEG-2 vid- 
eo within UDP data payload 111. 
[0023] Consistent with any size limitations placed on 
it, UDP data payload 1 1 1 may carry any arbitrary number 
of MPEG-2 transport stream packets 201. Each of 
MPEG-2 transport stream packets 201 is 188 bytes in 
length. By virtue of the definition of the MPEG-2 trans- 
port layer, the first byte of each of MPEG-2 transport 
stream packets 201 is always a so-called "sync" byte 
203, which has the value of 0x47. 
[0024] In accordance with the principles of the inven- 
tion, due to the regular spacing of the sync byte, it is 
possible to search through UDP data payload 111 for 
the presence of the expected pattern of MPEG-2 video, 
i.e., a pattern of having a sync byte as the first byte of 
UDP data payload 1 11 — after any optional RTP header- 
and thereafter having a sync byte at each byte position 
in UDP data payload 111 that is a multiple of 188. Al- 
though finding a sync byte as the first byte of UDP data 
payload 111, after any optional RTP header, gives a 
strong indication that the IP packet contains MPEG-2 
video, and it is assumed that for UDP data payloads of 
length 1 88 for which the first byte has the value of a sync 
byte that the packet contains MPEG-2 video, preferably 
each potential sync byte position should be checked. 
This is because the confidence level that MPEG-2 video 
has actually been found increases substantially when 
each position indeed contains a sync byte value. 
[0025] In the event that most of the expected positions 
contain a sync byte, but one or more do not, whether or 
not to declare the packet as one containing MPEG-2 vid- 
eo is at the discretion of the implementor when design- 
ing, or configuring, the system. For example, if only one 
position at which a sync byte would be expected was 
not a sync byte, and the IP packet was indicated to have 
a transmission error, then the implementor may decide 
to have the system still treat the packet as containing 
MPEG-2 video. 

[0026] FIG. 3 shows an exemplary process, in flow- 
chart form, for processing an IP packet to determine if 
it contains MPEG-2 video, in accordance with the prin- 
ciples of the invention. The process is entered in step 



301 when an IP packet is received. Next, in step 303, 
the packet is processed so there is a pointer that points 
to the UDP data payload within the packet, i.e., a pointer 
pointing within the packet is incremented to point to the 
UDP data payload. Thereafter, conditional branch point 
305 tests to determine if the length of the UDP data pay- 
load is a multiple of 188. If the test result in step 305 is 
YES, indicating that there is no RTP header and that the 
length of the UDP data payload corresponds to a multi- 
ple of the length of MPEG-2 transport stream packet, 
control passes to conditional branch point 307, which 
tests to determine if the byte of the UDP data payload 
being pointed to by the pointer has the value of a sync 
byte, e.g., 0x47. 

[0027] If the test result in step 307 is YES, control 
passes to step 309, which increments the pointer 188 
bytes, i.e., the length of an MPEG-2 transport stream 
packet. This should result in the pointer pointing either 
at a) the beginning of the next MPEG-2 transport stream 
packet or to the end of the UDP data payload, which is 
also the end of the packet, provided the UDP data pay- 
load actually contains MPEG-2 video, or b) just a ran- 
dom byte when the UDP data payload does not actually 
contain MPEG-2 video. Thereafter, control passes to 
conditional branch point 311, which tests to determine 
if the end of the IP packet has been reached. If the test 
result in step 311 is NO, indicating that there yet remains 
additional portions of the UDP data payload to process, 
control passes back to step 307 to process the rest of 
the packet as described above. If the test result in step 
311 is YES, control passes to step 31 3, and the IP pack- 
et is declared to be one containing MPEG-2 video, in 
accordance with an aspect of the invention. It may then 
be further processed accordingly. The process exits in 
step 315. 

[0028] If the test result in step 307 is NO, indicating 
that either the first byte or another byte at a 1 88 multiple 
position does not have the value of a sync byte, control 
passes to step 315 and the process is exited. 
[0029] If the test result in step 305 is NO, control pass- 
es to conditional branch point 31 7, which tests to deter- 
mine if the length of the UDP data payload is equal to a 
multiple of 188 plus the length of the RTP header. If the 
test result in step 317 is YES, indicating that the UDP 
data payload may contain an RTP header and thereafter 
MPEG-2 transport stream packets, control passes to 
step conditional branch point 319, which tests to deter- 
mine if the first bytes of the UDP data payload which 
correspond in length to an RTP header, have the char- 
acteristics of an RTP header, e.g., there is a video indi- 
cator in the location where the payload type field is ex- 
pected. More specifically, the payload type field is 7 bits, 
with the definition for MPEG-2 transport stream data be- 
ing 0x21 . 

[0030] If the test result in step 319 is NO, which indi- 
cates that there was no RTP header or that the header 
was not indicative of video, control passes to step 315 
and the process is exited without declaring the IP packet 
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to be one containing MPEG-2 video. If the test result in 
step 31 9 is YES, indicating that an RTP header for video 
was found, control passes to step 321, in which the 
pointer is incremented to point to the first byte after the 
RTP header. Control then passes to conditional branch 
point 307 and the process continues as described 
above. 

[0031] If the test result in step 317 is NO, indicating 
that the IP packet does not contain a whole number of 
MP EG -2 video transport stream packets, control passes 
to step 323, in which a counter variable COUNT, which 
is to be used as the offset into the UDP data payload, is 
set to 0. Next, conditional branch point 325 tests to de- 
termine if COUNT is equal to the sum of 188 and the 
length of an RTP header. If the test result in step 325 is 
YES, indicating that all the positions that could poten- 
tially contain a sync byte of a first MPEG-2 video trans- 
port stream packet in the UDP data payload have been 
tested and not been found to be a sync byte, the process 
is exited in step 315, i.e., the packet is not declared to 
contain MPEG-2 video. If the test result in step 325 is 
NO, indicating that all the positions that could potentially 
contain a sync byte of a first MPEG-2 video transport 
stream packet in the UDP data payload have not been 
tested, control passes to conditional branch point 327 
in which another pointer, PACKTPT, is set to the value 
of COUNT 

[0032] Thereafter, instep329,thebytewithintheUDP 
data payload pointed to by PACKTPT is tested to deter- 
mine if it has the value of a sync byte. If the test result 
in step 329 is NO, indicating that the byte currently point- 
ed to by PACKTPT is not a sync byte, control passes to 
step 331 in which COUNT is incremented, so that it will 
point to the next byte in the UDP data payload. Control 
then passes back to step 325, and the process contin- 
ues as described above. 

[0033] If the test result in step 329 is YES, indicating 
that the byte currently pointed to by PACKTPT indeed 
has the value of a sync byte, control passes to condi- 
tional branch point 333, which tests to determine if the 
remaining number of bytes in the packet from the place 
being pointed to by COUNT is less than 188. If the test 
result in step 333 is YES, indicating that a whole MPEG- 
2 video transport stream packet cannot be contained 
within the UDP data payload, control passes to step 315 
and the process is exited, i.e., the packet is not declared 
to contain MPEG-2 video. If the test result in step 333 
is NO, indicating that a whole MPEG-2 video transport 
stream packet could be contained within the UDP data 
payload, control passes to step 335, in which PACKTPT 
is incremented by 188. 

[0034] At this point, if the UDP data payload indeed 
contains MPEG-2 video and the byte currently pointed 
to by COUNT is a sync byte, the byte pointed to by 
PACKTPT should also have the value of a sync byte, or 
at or beyond the end of the packet. To this end, condi- 
tional branch point 337 tests to determine if the end of 
the packet has been reached or is exceed. If the test 



result in step 337 is NO, indicating that PACKIPT points 
to a byte within the UDP data payload, control passes 
back to step 329 and the process continues as de- 
scribed above. If the test result in step 337 is YES, in- 

s dicating that PACKTPT points to the end of the packet 
or beyond, control passes to step 31 3 and the process 
continues as described above. 
[0035] Note that the discussion herein with regard to 
IP refers to IP version 4, which is essentially universally 

10 in use as of the time of the writing of this application. 
Those of ordinary skill in the art will be readily able to 
apply the principles of the invention to later developed 
version of IP, such as proposed version 6, should one 
be implemented. 



Claims 

1. A method for processing an internet protocol (IP) 
20 packet (101 ,111), comprising the step of identifying 

that said packet contains motion picture expert 
group (MPEG)-2 video as a function of only the con- 
tents of said I P data payload (1 1 1 ) of said I P packet 
exclusive of any information in any real time proto- 
25 col (RTP) header which may be within said IP data 
payload. 

2. The method as defined in claim 1 wherein said 
MPEG-2 video is in transport stream format 

30 

3. The method as defined in claim I wherein said IP 
data payload contains at least one RTP packet 
which contains said MPEG-2 video. 

35 4. The method as defined in claim 1 wherein said IP 
data payload is an unreliable datagram protocol 
(UDP) data payload. 

5. The method as defined in claim 1 wherein said IP 
40 data payload is a transmission control protocol 

(TCP) data payload. 

6. The method as defined in claim 1 furthercomprising 
the step of processing said IP packet with a priority 

45 assigned for packets containing video when said 
packet is identified in said identifying step to contain 
video. 

7. The method as defined in claim 1 wherein said iden- 
50 tifying step further includes the steps of: 

determining whether or not there exists within 
said IP data payload at least an expected pat- 
tern of MPEG-2 sync bytes that is indicative of 
55 the presence of MPEG-2 video. 

8. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of: 
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comparing a first byte of said IP data payload 
after any realtime protocol (RTP) header to the 
value of an MPEG-2 sync byte; and 
when the result of said comparing step is that 
said first byte of said IP data payload has the s 
same value as an M PEG-2 sync byte, declaring 
said IP packet to be an MPEG-2 packet. 



9. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of; 

comparing a first byte of said IP data payload 
after any RTP header to the value of an MPEG- 
2 sync byte; and 

when the result of said comparing step is that 
said first byte of said IP data payload is an 
M P EG-2 sync byte and the length of said I P da- 
ta payload after any RTP header is the same 
as the length of an MPEG-2 transport stream 



data payload that is offset toward the end of 
said IP packet by the length of an MPEG-2 
transport stream packet; 
repeating said performing and adjusting steps 
so long as said most recently executed per- 
forming step declared said IP packet as a can- 
didate to be an MPEG-2 packet and the end of 
said IP data payload is not yet reached; and 



10 

declaring said packet to be an MPEG-2 packet 
when the end of said I P data payload is reached 
during an attempt to execute said adjusting 
step and said most recently executed perform- 
ing step declared said IP packet as a candidate 
to be an MPEG-2 packet. 

11. The method as defined in claim 7 wherein said ex- 
pected pattern is an MPEG-2 sync byte value 

10 spaced 188 byte positions apart. 

12. The method as defined in claim 7 wherein said ex- 
pected pattern is an MPEG-2 sync byte value 
spaced apart by the length of an MPEG-2 transport 

15 stream packet. 

13. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds sync 
byte for which offset therefrom by the length of 
one MPEG-2 transport stream packet there is 
another sync byte. 

14. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds the val- 
ue of a sync byte for which offset therefrom at 
each integral multiple of the length of one 
MPEG-2 transport stream packet there is the 
value of a sync byte until the end of said IP 
packet is reached or exceeded. 

15. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

declaring said IP packet to be an MPEG-2 
packet when a search over the length of a real 
time protocol header and the length of one 
MPEG-2 transport stream packet finds the val- 
ue of a sync byte for which offset therefrom by 
the length of one MPEG-2 transport stream 
packet there is the end of packet. 

16. The method as defined in claim 7 wherein said each 
of said sync bytes has a value of 0x47. 

55 17. The method as defined in claim 7 wherein said at 
least one expected pattern is the value of an MPEG- 
2 sync byte as the first byte of said IP data payload. 



packet, declaring said IP packet to be an 20 
MPEG-2 packet. 

10. The method as defined in claim 7 wherein said de- 
termining step further comprises the step of: 

25 

terminating said process and indicating that 
said expected pattern does not exist in said 
packet unless the length of said I P data payload 
or the length of said IP data payload less the 
length of a RTP header is an integral multiple 30 
of the length of an MPEG-2 transport stream 
packet; 

pointing a pointer to a byte in said IP data pay- 
load, said byte being a first byte of said IP data 
payload when said length of said IP data pay- 35 
load is an integral multiple of the length of an 
MPEG-2 transport stream packet and said byte 
being a first byte of said IP data payload after 
the length of a RTP header when said IP data 
payload less the length of a RTP header is an 40 
integral multiple of the length of an MPEG-2 
transport stream packet; 
performing a comparison between said byte 
being pointed to with the value of an MPEG-2 
sync byte and declaring said IP packet as a 45 
candidate to be an MPEG-2 packet when the 
result of a most recent comparison is that said 
pointed to byte of said IP data payload has the 
same value as an MPEG-2 sync byte 
adjusting said pointer to point to byte in said IP so 
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18. The method as defined in claim 7 wherein said ex- 
pected pattern is the value of an MPEG-2 sync byte 
as the first byte of said IP data payload and every 
1 88 bytes thereafter till the end of said IP data pay- 
load. 

19. The method as defined in claim 7 wherein said at 
least one expected patterns includes at least one of 
the sets of patterns consisting of: a) the value of an 
MPEG-2 sync byte as the first byte of said IP data 
payload after the length of a real time protocol 
(RTP) header (109) and said IP data payload after 
said RTP header length has a length of 1 88 bytes, 
b) the value of an MPEG-2 sync byte as the first 
byte of said IP data payload after the length of a real 
time protocol (RTP) header and every 188 bytes 
thereafter till the end of said IP data payload, c) the 
value of an MPEG-2 sync byte as the first byte of 
said IP data payload and every 188 bytes thereafter 
till the end of said IP data payload, d) the value of 
an MPEG-2 sync byte as the first byte of said IP 
data payload and said IP data payload has a length 
of 188 bytes. 

20. Apparatus, comprising: 

means for searching through a IP data payload 
(111) of an internet protocol (IP) packet (101, 
111) exclusive of any real time protocol (RTP) 
header therein for a pattern indicative of video; 
and 

means for indicating that said IP packet con- 
tains video when said pattern is found. 



Patentanspriiche 

1. Verfahren zum Verarbeiten eines Internet-Proto- 
koll-Pakets (IP-Pakets) (101, 111), umfassend den 
Schritt des Feststellens, dass das Paket MPEG-2 
Video (MPEG - "motion picture expert group") ent- 
halt, alsFunktionnurdeslnhaltsderlP-Datennutzin- 
formationen (111) des IP-Pakets ausschlieBlich der 
Informationen in einem beliebigen Echtzeitproto- 
koll-Anfangsblock ("real time protocol" - RTP), der 
sich in den IP-Datennutzinformationen befinden 
kann. 

2. Verfahren nach Anspruch 1 , wobei das MPEG-2 Vi- 
deo im Transportstromformat ist. 

3. Verfahren nach Anspruch 1, wobei die IP-Daten- 
nutzinformationen mindestens ein RTP-Paket ent- 
halten, welches das MPEG-2 Video enthalt. 

4. Verfahren nach Anspruch 1, wobei die IP-Daten- 
nutzinformationen unzuverlassige Datagramm- 
Protokoll-Datennutzinformationen ("unreliable da- 



tagram protocol" - UDP) sind. 

5. Verfahren nach Anspruch 1, wobei die IP-Daten- 
nutzinformationen Ubertragungsteuerungs-Proto- 

s koll-Datennutzinformationen ("transmission control 
protocol" - TCP) sind. 

6. Verfahren nach Anspruch 1 , des Weiteren umfas- 
send den Schritt des Verarbeitens des IP-Pakets 

10 mit einer Prioritat, die Paketen mit Video zugeord- 
net wird, wenn in dem Feststellungsschritt festge- 
stellt wird, dass das Paket Video enthalt. 

7. Verfahren nach Anspruch 1, wobei der Feststel- 
15 lungsschritt des Weiteren die folgenden Schritte 

umfasst: 

Bestimmen, ob in den IP-Datennutzinformatio- 
nen wenigstens ein erwartetes Muster von 
20 MPEG-2 Synchronisationsbytesvorhanden ist, 

das auf das Vorhandensein von MPEG-2 Video 
hinweist. 

8. Verfahren nach Anspruch 7, wobei der Bestim- 
25 mungsschritt des Weiteren folgenden Schritt um- 
fasst: 

Vergleichen eines ersten Bytes der IP-Daten- 
nutzinformationen nach einem beliebigen Echt- 
30 zeitprotokoll-Anfangsblock (RTP-Anfangs- 

block) mit dem Wert eines MPEG-2 Synchroni- 
sationsbytes; und 

wenn das Ergebnis des Vergleichsschrittes ist. 
35 dass das erste Byte der IP-Datennutzinforma- 

tionen denselben Wert wie ein MPEG-2 Syn- 
chronisationsbyte hat, Ausweisen des IP-Pa- 
kets als MPEG-2 Paket. 

40 9. Verfahren nach Anspruch 7, wobei der Bestim- 
mungsschritt des Weiteren folgenden Schritt um- 
fasst: 

Vergleichen eines ersten Bytes der IP-Daten- 
45 nutzinformationen nach einem beliebigen 

RTP-Anfangsblock mit dem Wert eines MPEG- 
2 Synchronisationsbytes; und wenn das Ergeb- 
nis des Vergleichsschrittes ist, dass das erste 
Byte der IP-Datennutzinformationen ein 
so M PEG-2 Synch ronisationsbyte ist und die Lan- 

ge der IP-Datennutzinformationen nach einem 
beliebigen RTP-Anfangsblock gleich derLange 
eines MPEG-2 Transportstrompakets ist, Aus- 
weisen des IP-Pakets als MPEG-2 Paket. 

55 

10. Verfahren nach Anspruch 7, wobei der Bestim- 
mungsschritt des Weiteren folgenden Schritt um- 
fasst: 
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Beenden des Prozesses und Anzeigen, dass 
das erwartete Muster in dem Paket nicht vor- 
handen ist, wenn nicht die Lange der IP-Daten- 
nutzinformationen Oder die Lange der IP-Daten- 
nutzinformationen minus der Lange eines 5 
RTP-Anfangsblocks ein ganzes Vielfaches der 
Lange eines MPEG-2 Transportstrompakets 
ist; 

Richten eines Pointers auf ein Byte in den w 
IP-Datennutzinformationen, wobei das Byte ein 
erstes Byte der IP-Datennutzinformationen ist, 
wenn die Lange der IP-Datennutzinformatio- 
nen ein ganzes Vielfaches der Lange eines 
MPEG-2 Transportstrompakets ist und das By- is 
te ein erstes Byte der IP-Datennutzinformatio- 
nen nach der Lange eines RTP-Anfangsblocks 
ist, wenn die IP-Datennutzinformationen minus 
der Lange eines RTP-Anfangsblocks ein gan- 
zes Vielfaches der Lange eines MPEG-2 20 
Transportstrompakets ist; 

Durchfuhren eines Vergleichs zwischen dem 
Byte, auf das der Pointer gerichtet ist, mit dem 
Wert eines MPEG-2 Synchronisationsbytes 25 
und Ausweisen des IP-Pakets als Kandidaten 
fur ein MPEG-2 Paket, wenn das Ergebnis ei- 
nes jungsten Vergleichs ist, dass das Byte der 
IP-Datennutzinformationen, auf das der Poin- 
ter gerichtet ist, denselben Wert hat wie ein 30 
MPEG-2 Synchronisationsbyte; 

Einstellen des Pointers, so dass er auf ein Byte 
in den IP-Datennutzinformationen gerichtet ist, 
das urn die Lange eines MPEG-2 Transport- 35 
strompakets zu dem Ende des IP-Pakets ver- 
setzt ist; 

Wiederholen der Durchfuh rungs- und Einstel- 
lungsschritte, bis der zuletzt ausgefiihrte 40 
Durchfiihrungsschritt das IP-Paket als Kandi- 
daten fur ein MPEG-2 Paket ausweist und das 
Ende der IP-Datennutzinformationen noch 
nicht erreicht ist; und 

45 

Ausweisen des Pakets als MPEG-2 Paket, 
wenn das Ende der IP-Datennutzinformationen 
wahrend eines Versuchs, den Einstellungs- 
schritt auszufuhren, erreicht wird und der zu- 
letzt ausgefiihrte Durchfiihrungsschritt das so 
IP-Paket als Kandidaten fur ein MPEG-2 Paket 
ausweist. 

11. Verfahren nach Anspruch 7, wobei das erwartete 
Muster ein MPEG-2 Synch ronisationsbytewert in ss 
einem Abstand von 188 Bytepositionen ist. 

12. Verfahren nach Anspruch 7, wobei das erwartete 



Muster ein MPEG-2 Synch ronisationsbytewert in 
einem Abstand von der Lange eines MPEG-2 
Transportstrompakets ist. 

13. Verfahren nach Anspruch 7, wobei der Bestim- 
mungsschritt des Weiteren folgenden Schritt um- 
fasst: 

Ausweisen des IP-Pakets als MPEG-2 Paket, 
wenn eine Suche iiber die Lange eines Echt- 
zeitprotokoll-Anfangsblocks und die Lange ei- 
nes MPEG-2 Transportstrompakets ein Syn- 
chronisationsbyte ergibt, zu dem ein anderes 
Synchronisationsbyte urn die Lange eines 
MPEG-2 Transportstrompakets versetzt ist. 

14. Verfahren nach Anspruch 7, wobei der Bestim- 
mungsschritt des Weiteren folgenden Schritt um- 
fasst: 

Ausweisen des IP-Pakets als MPEG-2 Paket, 
wenn eine Suche iiber die Lange eines Echt- 
zeitprotokoll-Anfangsblocks und die Lange ei- 
nes MPEG-2 Transportstrompakets den Wert 
eines Synchronisationsbytes ergibt, zu dem 
der Wert eines Synchronisationsbytes bei je- 
dem ganzen Vielfachen der Lange eines 
MPEG-2 Transportstrompakets versetzt ist, bis 
das Ende des IP-Pakets erreicht ist Oder uber- 
schritten wird. 

15. Verfahren nach Anspruch 7, wobei der Bestim- 
mungsschritt des Weiteren folgenden Schritt um- 
fasst: 

Ausweisen des IP-Pakets als MPEG-2 Paket, 
wenn eine Suche iiber die Lange eines Echt- 
zeitprotokoll-Anfangsblocks und die Lange ei- 
nes MPEG-2 Transportstrompakets den Wert 
eines Synchronisationsbytes ergibt, zu dem 
das Ende des Pakets urn die Lange eines 
MPEG-2 Transportstrompakets versetzt ist. 

16. Verfahren nach Anspruch 7, wobei jedes der Syn- 
chronisationsbytes einen Wert von 0x47 hat. 

17. Verfahren nach Anspruch 7, wobei das wenigstens 
eine erwartete Muster der Wert eines MPEG-2 Syn- 
chronisationsbytes als das erste Byte der IP-Daten- 
nutzinformationen ist. 

18. Verfahren nach Anspruch 7, wobei das wenigstens 
eine erwartete Muster der Wert eines MPEG-2 Syn- 
chronisationsbytes als das erste Byte der IP-Daten- 
nutzinformationen und alle 188 Bytes danach bis 
zum Ende der IP-Datennutzinformationen ist. 

19. Verfahren nach Anspruch 7, wobei das wenigstens 
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eine erwartete Muster wenigstens einen der Mu- 
stersatze enthalt, bestehend aus: a) dem Wert ei- 
nes MPEG-2 Synch ronisationsbytes als das erste 
Byte der IP-Datennutzinformationen nach der Lan- 
ge eines Echtzeitprotokoll-Anfangsblocks (RTP-An- 
fangsblocks) (1 09), wobei die IP-Datennutzinforma- 
tionen nach der RTP-Anfangsblocklange eine Lan- 
ge von 1 88 Bytes haben, b) dem Wert eines M PEG- 
2 Synch ronisationsbytes als das erste Byte der 
IP-Datennutzinformationen nach der Lange eines 
Echtzeitprotokoll-Anfangsblocks (RTP-Anfangs- 
blocks) und alle 1 88 Bytes danach bis zum Ende 
der IP-Datennutzinformationen, c) dem Wert eines 
MPEG-2 Synchronisationsbytes als das erste Byte 
der IP-Datennutzinformationen und alle 188 Bytes 
danach bis zum Ende der IP-Datennutzinformatio- 
nen, d) dem Wert eines MPEG-2 Synchronisations- 
bytes als das erste Byte der IP-Datennutzinforma- 
tionen, wobei die IP-Datennutzinformationen eine 
Lange von 188 Bytes haben. 

20. Vorrichtung, umfassend: 

Mittel zum Durchsuchen von I P-Datennutzinfor- 
mationen (111) eines Internet-Protokoll-Pakets 
(IP-Pakets) (101, 111) ausschlieBlich eines be- 
liebigen Echtzeitprotokoll-Anfangsblocks 
(RTP-Anfangsblocks) darin nach einem Mu- 
ster, das auf Video hinweist; und 

Mittel zum Anzeigen, dass das IP-Paket Video 
enthalt, wenn das Muster gefunden wird. 



Revendications 

1 . Precede de traitement d'un paquet de protocole In- 
ternet (IP) (101 , 111), comprenant I'etape d'identifi- 
cation que ledit paquet contient de la video selon le 
motion picture expert group (MPEG)-2 en fonction 
uniquement du contenu de ladite charge utile de 
donn6es IP (111) dudit paquet IP a I'exclusion de 
toute information dans un quelconque en-tete de 
protocole en temps reel (RTP) pouvant se trouver 
dans ladite charge utile de donn6es IP. 

2. Procede selon la revendication 1 , dans lequel ladite 
video MPEG-2 est en format de train de transport. 

3. Procede selon la revendication 1 , dans lequel ladite 
charge utile de donnees IP contient au moins un 
paquet RTP qui contient ladite video MPEG-2. 

4. Procede selon la revendication 1 , dans lequel ladite 
charge utile de donnees IP est une charge utile de 
donnees de protocole de datagramme peu fiable 
(UDP). 



5. Procede selon la revendication 1 , dans lequel ladite 
charge utile de donnees IP est une charge utile de 
donnees de protocole de commande de transmis- 
sion (TCP). 

5 

6. Procede selon la revendication 1, comprenant en 
outre I'etape de traitement dudit paquet I P avec une 
priorite attribuee aux paquets contenant de la video 
quand ledit paquet est identifie dans ladite etape 

10 d'identification comme contenant de la video. 

7. Proc6d6 selon la revendication 1 , dans lequel ladite 
etape d'identification comporte en outre les etapes 
de: 

15 

determination s'il existe ou non dans ladite 
charge utile de donnees IP au moins une con- 
figuration attendue d'octets de synchronisation 
MPEG-2 qui est indicative de la presence de 
20 video MPEG-2. 

8. Procede selon la revendication 7, dans lequel ladite 
etape de determination comprend en outre I'etape 
de; 

25 

comparaison d'un premier octet de ladite char- 
ge utile de donnees I P apres n'importe quel en- 
tete de protocole en temps reel (RTP) a la va- 
leur d'un octet de synchronisation MPEG-2 ; et 
30 quand le resultat de ladite etape de comparai- 

son est que ledit premier octet de ladite charge 
utile de donnees IP a la m£me valeurqu'un oc- 
tet de synchronisation MPEG-2, declaration 
dudit paquet IP comme etantun paquet MPEG- 

35 2. 

9. Procede selon la revendication 7, dans lequel ladite 
etape de determination comprend en outre I'etape 
de: 

40 

comparaison d'un premier octet de ladite char- 
ge utile de donnees IP apres n'importe quel en- 
tete RTP a la valeur d'un octet de synchronisa- 
tion MPEG-2 ; et 

45 quand le resultat de ladite etape de comparai- 

son est que ledit premier octet de ladite charge 
utile de donnees IP est un octet de synchroni- 
sation MPEG-2 et que la longueur de ladite 
charge utile de donnees IP apres n'importe 

so quel en-tete RTP est identique a la longueur 

d'un paquet de train de transport MPEG-2, de- 
claration dudit paquet IP comme etant un pa- 
quet MPEG-2. 

55 1 o. Procede selon la revendication 7, dans lequel ladite 
6tape de determination comprend en outre I'etape 
de: 



20 



25 
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terminaison dudit processus et indication que 
ladite configuration attendue n'existe pas dans 
ledit paquet a moins que la longueur de ladite 
charge utile de donnees IP ou la longueur de 
ladite charge utile de donnees IP moins la lon- 
gueur d'un en-tete RTP ne soit un multiple en- 
tier de la longueu r d'un paquet de train de trans- 
port MPEG-2 ; 

pointage d'un pointeur vers un octet dans ladite 
charge utile de donnees IP, ledit octet etant un 
premier octet de ladite charge utile de donnees 
IP quand ladite longueur de ladite charge utile 
de donnees IP est un multiple entierde la lon- 
gueur d'un paquet de train de transport MPEG- 
2 et ledit octet etant un premier octet de ladite 
charge utile de donnees IP apres la longueur 
d'un en-tete RTP quand ladite charge utile de 
donnees IP moins la longueurd'un en-tete RTP 
est un multiple entier de la longueur d'un pa- 
quet de train de transport MPEG-2 ; 
execution d'une comparaison entre ledit octet 
faisant I'objet d'un pointage a la valeur d'un oc- 
tet de synchronisation MPEG-2 et declaration 
dudit paquet IP comme candidat pouvant etre 
un paquet MPEG-2 quand le resultat d'une 
comparaison executee le plus recemment est 
que ledit octet faisant I'objet d'un pointage de 
ladite charge utile de donnees IP a la meme 
valeur qu'un octet de synchronisation MPEG- 
2 ; 

reglage dudit pointeur pour qu'il pointe sur un 
octet dans ladite charge utile de donnees IP qui 
est decale vers la fin dudit paquet IP par la lon- 
gueur d'un paquet de train de transport MPEG- 
2; 

repetition desdites etapes d'execution et de re- 
glage tant que ladite etape d'execution execu- 
tee le plus recemment a declare ledit paquet IP 
comme candidat pouvant etre un paquet 
MPEG-2 et que la fin de ladite charge utile de 
donnees IP n'est pas encore atteinte ; et 
declaration dudit paquet comme etant un pa- 
quet MPEG-2 quand la fin de ladite charge utile 
de donnees IP est atteinte durant une tentative 
d'execution de ladite 6tape de reglage et que 
ladite etape d'execution executee le plus re- 
cemment a declare ledit paq uet I P comme can- 
didat pouvant etre un paquet MPEG-2. 

1 1 . Precede selon la revendication 7, dans lequel ladite 
configuration attendue est une valeur d'octet de 
synchronisation MPEG-2 espacee par des posi- 
tions de 188 octets, 

12. Procede selon la revendication 7, dans lequel ladite 
configuration attendue est une valeur d'octet de 
synchronisation MPEG-2 espacee par la longueur 
d'un paquet de train de transport MPEG-2. 



13. Procede selon la revendication 7, dans lequel ladite 
etape de determination comprend en outre I'etape 
de: 

5 declaration dudit paquet IP comme etant un pa- 

quet MPEG-2 quand une recherche sur la lon- 
gueur d'un en-tete de protocole en temps reel 
et la longueur d'un paquet de train de transport 
MPEG-2 trouve I'octet de synchronisation pour 

10 lequel le decalage a partir de celui-ci par la lon- 

gueur d'un paquet de train de transport MPEG- 
2 est un autre octet de synchronisation. 

1 4. Procede selon la revendication 7, dans lequel ladite 
'5 etape de determination comprend en outre I'etape 

de: 

declaration dudit paquet IP comme etant un pa- 
quet MPEG-2 quand une recherche sur la lon- 

20 gueur d'un en-tete de protocole en temps reel 

et la longueur d'un paquet de train de transport 
M PEG-2 trouve la valeur d'un octet de synchro- 
nisation pour lequel le decalage a partir de ce- 
lui-ci a chaque multiple entier de la longueur 

25 d'un paquet de train de transport MPEG-2 est 

la valeur d'un octet de synchronisation jusqu'a 
ce que la fin dudit paquet IP soit atteinte ou de- 
passee. 

30 1 5. Procede selon la revendication 7, dans lequel ladite 
etape de determination comprend en outre I'etape 
de: 

declaration dudit paquet I P comme etant un pa- 
ss quet MPEG-2 quand une recherche sur la lon- 
gueur d'un en-tete de protocole en temps reel 
et la longueur d'un paquet de train de transport 
MPEG-2 trouve la valeur d'un octet de synchro- 
nisation pour lequel le decalage a partir de ce- 
40 |ui-ci par la longueur d'un paquet de train de 
transport MPEG-2 est la fin du paquet. 

16. Procede selon la revendication 7, dans lequel cha- 
que dit octet de synchronisation a une valeur de 

45 0x47. 

17. Procede selon la revendication 7, dans lequel ladite 
au moins une configuration attendue est la valeur 
d'un octet de synchronisation MPEG-2 comme pre- 

50 mier octet de ladite charge utile de donnees IP. 

1 8. Procede selon la revendication 7, dans lequel ladite 
configuration attendue est la valeur d'un octet de 
synchronisation MPEG-2 comme premier octet de 

55 ladite charge utile de donnees IP et tous les 188 
octets apres cela jusqu'a la fin de ladite charge utile 
de donnees IP. 
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19. Procede selon la revendication 7, dans lequel ladite 
au moins une configuration attendue comporte au 
moins un des ensembles de configurations consis- 
tant en : a) la valeur d'un octet de synchronisation 
MPEG-2 comme premier octet de ladite charge utile s 
de donnees IP apres la longueur d'un en-tete de 
protocole en temps reel (RTP) (1 09) et ladite charge 
utile de donnees IP apres ladite longueur d'en-tete 
RTP a une longueur de 1 88 octets, b) la valeur d'un 
octet de synchronisation MPEG-2 comme premier 10 
octet de ladite charge utile de donnees IP apres la 
longueur d'un en-tete de protocole en temps reel 
(RTP) et tous les 188 octets apres cela jusqu'a la 

fin de ladite charge utile de donnees, c) la valeur 
d'un octet de synchronisation MPEG-2 comme pre- is 
mier octet de ladite charge utile de donnees IP et 
tous les 1 88 octets apres cela jusqu'a la fin de ladite 
charge utile de donnees, d) la valeur d'un octet de 
synchronisation MPEG-2 comme premier octet de 
ladite charge utile de donnees IP et ladite charge 20 
utile de donnees IP a une longueur de 1 88 octets. 

20. Dispositif, comprenant : 

un moyen de recherche dans une charge utile 25 
de donnees IP (111) d'un paquet de protocole 
Internet (IP) (101, 111) a I'exclusion de tout en- 
tete de protocole en temps reel (RTP) dans ce- 
lui-ci d'une configuration indicative de video ; et 
un moyen d'indication que ledit paquet IP con- 30 
tient de la video quand ladite configuration est 
trouvee. 
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